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Here is Module 9: 
Tools and Tricks for Program Design. 


The problem-solving, design, and coding skills that you sharpened in your 
previous modules are essential to successful programming. These skills lose 
their edge, however, if they're not used efficiently. 


Module 9 teaches you a number of tricks of the trade used by professionals 
to speed up and simplify the design and coding of new programs. Among other 
things, you will specifically learn how to: 


* Maintain a software library at all levels of development. 


x Use structured programming for all tasks to reduce design and 
debugging time. 


* Identify key parts of a program where efficient coding is essential. 


Besides all this, your program disk contains both the source code and the 
object code for a sideways printing program. This is a working version of the 
program originally listed in Module 8, and which you worked on while waiting 
for this module. 


The conversion of this program from 8088 assembly language to 6502 
assembly language was somewhat tedious, and more complex than might be 
expected. The program on you disk was designed for a Gemini 10X printer having 
a standard parallel printer interface, and a commercial interface unit 
connected between the printer and the Commodore serial bus. If your printer is 
different or you have a different interface unit, you may need to adjust the 
secondary address sent to the interface unit, and possibly the printer control 
codes as well. We strongly urge that you look over this program and compare it 
closely with your version. 


With these inside tips and the skills you have mastered so far, you should 
easily clear your final hurdle. Module 10: Writing Advanced Programs, carries 
you well beyond fundamental program structure into more complex programming 
concepts and applications. You'll also pick up many more valuable tools and 
tricks that you can use in the design of your own programs. 


Also in Module 10, we will discuss in detail the problems encountered in 
writing and debugging the PDSW program. This discussion will provide a much 
deeper insight into the operation of the 6502 microprocessor, along with its 
advantages and limitations. 


Sincerely, - 
Kenneth J. Bigelow 
Project Engineer 
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This is Module 9 of your Contemporary Program- 
ming and Software Design Series. In this module, 

. you will learn a number of the techniques used by 
programmers to simplify the programming process 
and to speed up the production and execution of 
new programs. 

As you gain programming experience, you begin 
to see connections between one kind of program 
and another; you find that a technique or procedure 
which you developed for one task applies to other 
tasks equally well; you also begin to see relation- 
ships that were not previously apparent. Because of 
these relationships, you can very often use part of 
one program to perform a similar function in 
another program. You can use the same block of 
code in a number of different programs or even 
modify one program to perform a different but 
related function. 

In this module, we will explore a number of 
different ways in which we can shorten and simplify 
the programming process. As with earlier modules 
in this series, the Program Disk provided with this 
module is formatted for use with the Commodore 64 
computer and 1541 disk drive. The disk is also 
compatible with the Commodore 128 in 64 mode 
and with the 1741 drive. It is formatted single sided, 
with 35 tracks. ‘ 

The demonstration programs on this disk are 
copyright ©1987, 1988 by McGraw-Hill, Inc. You 
may back them up for archival copies or for your 
own use, but you may not give or sell them to 
anyone else. We suggest that you do use the 
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BACKUP program we provided in Module 1 to 
make a copy of this disk and then put the original 
disk away, with a write-protect tab installed on it. 
Then, if you should happen to damage your working 
disk, you can make a new working disk by backing 
up the original one again. 

Whenever you run the demonstration programs, 
remember that your working disk must be in Drive 
8. Some programs load and run other programs 
from the disk and will look for them on that drive; 
therefore, even if you have more than one disk drive 
on your computer system, be sure to use Drive 8 for 
this module. 

To begin learning some of the tools and tricks 
commonly used by programmers to simplify their 
work, turn on your computer system and load your 
Program Disk or backup into Drive 8. Then, type in 
the commands: 


LOAD “WELCOME”<return> 
RUN<return> 


When your computer tells you to turn to your 
Learning Guide, start on page one. 
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TOOLS AND TRICKS 
FOR PROGRAM DESIGN 


There is a large number of techniques used by all 
programmers to simplify their work. Some methods 
are developed by the individual programmer to suit 
his or her style of working, and are of little use to 
others. Other methods are shared and become 
widely used, because they apply to many pro- 
grammers. In this module, we will see examples of 
several different kinds of techniques. You should try 
them all and decide which methods are suited to 
your own use and which are not. By the end of the 
module, you will have an idea of which techniques 
you will keep, and which ones you will put aside for 
the present. 

While there are many different techniques in use 
to simplify and shorten program design, they gener- 
ally fall into a few clear categories. Also, most tech- 
niques are aimed at avoiding the needless repetition 
of some task. Thus, if we group these techniques 
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together into their separate classifications, we will 
be able to find clear relationships between them. 

If you haven’t already, load your Program Disk in 
Drive 8. Then type in the commands: 


LOAD “WELCOME”’<return> 
RUN<return> 


Return to this point when the computer instructs 
you to do so. 

Many of the techniques you will learn must be 
adjusted to suit different computer languages and 
different situations. The concepts are basically the 
same in each case; only the specific implementation 
must be modified. 

With these thoughts in mind, let’s speed our way 
into this Learning Guide, so we can see how to 
speed up the development of our programs. 
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NOTES: 


2 MODULE 9 


TRACK 1 


CLASSIFICATION OF 


DEVELOPMENT TOOLS 


Program development tools may be classified in a 
number of different ways, depending on how you 
want to group them. However, they all add up to the 
same basic rules: 

1. Don’t do any job more than once. Do it the first 
time, and then save the fruits of your labor. If you 
need those particular results again (and it’s likely 
you will), you will still have them. Always keep 
copies of your work. 

2. Don’t overcomplicate your work. Keep the 
simple tasks simple, and save the complexities for 
tasks that require them. (You might wish to deliber- 
ately complicate a program if you plan to keep oth- 
ers from deciphering and modifying it, but don’t do it 
unless you are doing it on purpose.) This is often 
known informally as the “KISS” principle (Keep It 
Simple, Stupid). 

3. Build up a “software library.” This is not just a 
library of complete programs, but also a library of 
functional software blocks that can be readily 
incorporated into other programs. This may include 
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source code in any languages you may be using, 
object modules that may be linked to other 
modules, or even relocatable machine code subrou- 
tines that can be “tacked” onto the end of a pro- 
gram, and the program patched to use them. It may 
also include books of algorithms and arithmetic 
procedures which you can implement whenever 
you may need them. 

Rule number 3 is related to rule number 1, and 
can help you with it. However, they are not the same 
and your program designs will be more effective if 
you keep them all in mind. Now, let’s take a closer 
look at each of these rules. In later tracks, we will 
see some detailed examples. 


Sector 1: Doing the Job Once and Only Once 


Time and time again even experienced program- 
mers find themselves doing the same thing over and 
over again. This does not mean that you should not 
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follow the same general procedures as you design 
each new program; you should. Each time you 
design a new program, however, it should be to. 
perform a new task, or at least to perform a task 
better than any other program does. 

For example, suppose you need a program to 
search all disk drives to look for a requested file. If no 
disk is in a drive, that drive is to be ignored and no 
error message given unless all drives have been 
checked and the file is not present anywhere. 

Most programmers would immediately start 
listing the requirements of such a program, check 
kernal functions, etc. This is not the correct way to 
start, unless you know that you have no such 
program already available. Instead, you should start 
by looking through an index of programs, either one 
downloaded from a bulletin-board service, a public- 
domain software copy service, a retail store, or one 
that you have previously designed yourself. Each 
time you write or acquire a new program, you 
should add it to the index. Organize the index by 
function and include a brief description of each 
program, together with its name, and the identifi- 
cation of the disk where it is stored. 

By taking a few minutes to check what you 
already have, you can sometimes avoid a multi-day 
or multi-week program design chore. Otherwise, 
you may find when you start cataloging your pro- 
grams that you have written the same program 
three or four times in three or four different ways, 
when only one such effort was necessary. 

The use of such an index can also save you from 
downloading or purchasing multiple copies of the 
same or very similar programs. 


Sector 2: The KISS Principle 


There are always many ways to design and imple- 
ment any program or function. For example, to add 
1 to an 8-bit number at a location in memory 
designated COUNT, we could use any of the 
following assembly-language sequences: 


INC COUNT 
LDX COUNT 
INX 

STX COUNT 
LDA COUNT 
CLC 

ADC #1 

STA COUNT 


Clearly, the first instruction is the simplest, and 
should be preferred. It will not only require the least 
space in the program, but will also execute the 
fastest. Therefore, unless you have compelling rea- 
sons to use some other instructions that are 
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required by your program logic, you should always 
use this first instruction for that purpose. 

This same logic holds for functional blocks of 
code, as well as for higher level languages. You 
might wish to do something in a more complicated 
way while checking out a particular algorithm or 
establishing the best way to accomplish a particular 
task. Once you have that procedure established, 
you should follow it in the simplest possible way. 

The simpler a program is, the easier it is for you or 
anyone else to understand, document, update, and 
modify. If you make it more complicated than it 
needs to be, you will be making trouble for yourself 
as well as for others. 


Sector 3: Setting Up a Software Library 


As you make more and more use of your computer, 
design programs, purchase programs, or acquire 
public domain and “shareware” programs, you will 
find a number of them that are not particularly 
useful to you at that time, and others that most 
definitely are useful. In each case, you should 
determine the limits and capabilities of each pro- 
gram and note these on an index of programs you 
have. 

This index should be organized by function. That 
is, you should have a section for text editors and 
word processors, one for database management 
programs, one for languages (assemblers and 
compilers), one for spreadsheets, one for system 
utilities, etc. Under word processors, you would 
include every text editor and word processing 
program you have ever acquired, no matter how 
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simple or how sophisticated. You might also list 
spelling checkers, grammar checkers, hyphenation 
programs, and assorted letter-quality printer driver 
programs in this category of your index. 

In the same way, you would list all of your 
database manager programs, including your 
PHONEBOOK program (which is a very simple 
example) and any others you may have acquired. 
This category would also include specialized utility 
programs to translate database data files from one 
format to another. 

As you design your own programs for your own 
purposes, add these to the list. These can (and very 
often will) include functional blocks as well as com- 
plete programs. Most languages or at least text 
editors will include ways to include a complete block 
of source code or other text into an existing pro- 
gram or document. Thus, if you have a useful sub- 
routine in BASIC, you can assign it a set of line 
numbers so high that no program you ever write will 
have them. For example, you might use line 
numbers 50,000 and above for this purpose. Then 
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save the subroutine in ASCII format (with the ,A 
option), and you can MERGE it into any program 
you like. 

Similarly, you might have a “blank” assembly- 
language code file. Such a file would contain all of the 
necessary headers and format codes, as well as a 
series of equates to define labels that you would 
commonly use in all programs. These might include 
ASCII code definitions for CR, LF, BS, BEL, etc., as 
well as calls to the Kernal ROM. If you have an 
assembler that recognizes macros, your standard 
macros would also be defined. Now whenever you 
code a new program, you can start with this blank 
file and never have to individually enter these 
definitions again. 

Each time you develop or acquire a new program, 
be prepared to use all or part of it in other programs. 
This helps to avoid duplication of effort and also 
promotes a clearer understanding of each program 
individually, and programming in general. 

Now that we have an idea of some of the ways we 
can streamline program design and development, 
let’s take a look at some of the specific tools and 
methods that can be used for this purpose. 


A 
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SIMPLIFYING THE PAPER DESIGN 


OF A PROGRAM 


As you learned in the first few modules of your 
Series, the initial design of any program is done on 
paper, rather than on a computer. This is because 
you cannot key meaningful instructions into a com- 
puter until you have determined what instructions 
(and in what order) you want to use to accomplish 
your purpose. 

The paper design procedure is often tedious and 
time-consuming. The initial problem statement and 
basic solution concepts are generally easy enough. 
However, the detailed solution procedure is more 
difficult to specify. Therefore, anything we can do to 
make this procedure shorter and easier, either now 
or in the future, is well worthwhile. 

A number of techniques have been developed to 
simplify, shorten, or break up the process of design- 
ing a program. They are commonly used in the 
design of large programs, but many of these tech- 
niques also apply to small programs. They are well 
worth considering for any program you write. 
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Sector 1: Break Up the Program into Smaller 
Tasks 


Acommon problem with the development of a large 
program is that it seems overwhelming at the start. 
Therefore, it is easy to give up on it as “too much 
work right now.” However, it is not necessary to 
work on the whole program as a single unit. 

When a software development company such as 
MicroPro™ (WordStar, CalcStar, Mailmerge, etc.) 
or Ashton-Tate (dBase II and III), Borland (Turbo 
Pascal), or Lotus (1-2-3, Symphony) designs a new 
program, a team of programmers is assigned to the 
task. Each programmer is assigned a specific func- 
tion to design and debug, and no one programmer is 
required to handle the whole program. 

A single programmer might be called upon to 
design the conditional operation structure of the 
program (IF ... THEN, CASE structures, WHILE 
... DO constructions, and loops). Another 
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programmer might deal only with I/O operations 
involving disk files, while a third would be concerned 
with printer output formatting and control. Only 
one programmer would design the command inter- 
preter, while others would be assigned, one-on-one, 
to design the command handling routines. 

In this manner, no one programmer has too large 
a burden, and the only requirement is that a few 
basic rules be followed regarding the use of registers 
or stack memory for passing data, as well as 
memory usage restrictions. By following the given 
rules, each programmer can make sure that his or 
her program module will be compatible with all of 
the other program modules that will go together to 
make up the completed product. 

In exactly the same way, you can decide on the 
basic program structure you want and the rules you 
want to follow for passing data back and forth 
around the program. Then you can design each 
individual program module by itself, and test its 
operation completely, before you put the whole 
program together. 

For example, you might design the initialization 
routine first and make sure, using NRIBUG, that it 
correctly initializes whatever peripheral devices, 
CPU registers, and memory locations will be 
required by the main program. Then you can put 
this routine aside and work on the next routine. 

The second routine might be the program’s 
command processor, which is sometimes known as 
the “idle loop.” This is the series of instructions that 
waits for a user input and then checks it to see if it is 
valid. If so, it calls forth the appropriate command 
handling routine. 


Once you have the command processor and 
initialization routines working correctly, you can 
use them to test individual handling routines as you 
develop them, and add the additional routines to the 
overall program one at a time. This approach has 
the added advantage that it remains expandable, so 
if you wish to add another command at a later time, 
you can do so more easily. 


Sector 2: Structured Programming 


The procedure of developing each task or func- 
tional block by itself and then building the program 
from these blocks tends to lend a logical structure to 
the overall program. If you follow a few simple rules 
in the development of each block of code, you can 
also maintain a logical structure within those blocks. 

There are several advantages to maintaining a 
true program structure. A correctly structured pro- 
gram is easier to trace through, debug, update, and 
modify than an unstructured program. Further- 
more, if you maintain the structure of the program 
during any changes, future changes will also be 
easier. 

In Module 8, we showed how an extra block of 
code could be tacked onto the end of an existing 
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program, and then either jumped to or called as a 
subroutine. This is an unstructured technique, and 
is undesirable if it can be avoided. We realize that it 
cannot always be avoided, especially in a program 
you have purchased or obtained from a public 
domain source. However, you should never seek to 
design a program along these lines. If you do, you 
will have no coherent outline or structure to the 
program, and you will have a very hard time even 
with the initial debugging phases, let alone later 
updates. Unstructured code (often called “spa- 
ghetti code”) leads to confusion and sloppiness, and 
frequently causes programmers to give up in dis- 
gust. It is often easier to design a program over 
again, rather than correct or update an unstruc- 
tured program. 

Designing a program in structured form is not 
really difficult. Some high-level languages (such as C 
and Pascal) are deliberately designed to promote 
structured programming. Even when using a lan- 
guage that does not promote structured designs, it 
is not difficult to maintain proper structure through- 
out your program. There are only a few simple rules 
to follow in order to produce and maintain struc- 
tured programs. 

Design each task, routine, and subroutine to 
have one entry point and one exit point. You 
can still include subroutine calls in your code as 
needed, but each such subroutine should still have 
only one entry point (the first instruction to be exe- 
cuted) and one exit point (the RTS instruction). 
Avoid allowing part of a subroutine to operate as a 
separate subroutine as well. Instead, design the 
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innermost routine as a separate subroutine, and 
have the large routines call it as necessary. By the 
same token, do not permit multiple RET instruc- 
tions within a subroutine. Have all possible paths 
through the routine lead to the same RET instruc- 
tion. You will be glad for this when you try to debug 
the program and want to check the operation of the 
subroutine. You need only put a breakpoint at the 
single exit, rather than trying to cover all possible 
exits. In addition, you won’t have to wonder which 
exit was used. 

Avoid the use of unconditional jumps or 
GOTO instructions. Most of your program code 
should be straight-line instructions in memory. 
Conditional operations (IF ... THEN ... ELSE 
logic), program loops, and subroutine calls are fine, 
and do not constitute structure violations. Extra 
jumps to various parts of memory and then back 
again are unstructured, and should not be used. 

Standardize your functional procedures. 
This means that you should decide initially how you 
want to pass information from one routine to 
another and use the same techniques throughout 
the program. It also means you need to use the same 
method for flagging the success or failure of an 
operation. For example, it isa common technique to 
use the Carry flag (C) to indicate that an operation 
failed. Thus, if C=0 upon return from a subroutine, 
the operation was successful. If C=1, the operation 
has failed. If a failure is indicated, register A contains 
a code that indicates the nature of the failure. 
Whether you adopt this convention or use a 
different one, be consistent. Make the Carry flag 
mean the same thing for each routine and return the 
error code in the same register every time. Similarly, 
always use a constant procedure for passing data to 
a functional routine or subroutine. 
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By following these simple rules, you will find that 
many of the “mechanical” design decisions fall into 
place, so that you can concentrate your design 
efforts on the actual working purpose of the pro- 
gram. In addition, you will find your program easier 
to debug, document, and update than it otherwise 
might be. 


Sector 3: Work on Only One Task at a Time 


It may seem unnecessary to specify this, but dis- 
tractions tend to creep in anywhere and every- 
where. Unfortunately, it is impossible (at least for 
most people) to concentrate on two different things 
at one time. Therefore, if you are working on one 
routine and decide that here you will call a subrou- 
tine to perform a particular task, simply make note 
of that fact for the moment, and continue on with 
the routine. Wait until later to work on the 
subroutine. 

The reason for this is that you can concentrate 
better on the overall procedure if you don’t worry 
about the little details. Keep your mind working at 
the same program level until you have completed 
the routine. In fact, it is best if you complete all of the 
routines at one level before going on to the next 
level. If you do go down a level or two and start 
working on the subroutines, you are very likely to 
lose track of what you were originally doing. Then, 
when you do complete the subroutines, you will 
have to go back and figure out where you were. It is 
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far better to complete one train of thought before 
switching to another. 

In addition, this one-level-at-a-time procedure 
contributes to structured program design. That is, if 
you first deal with the top level and define the basic 
program sequence, and then drop down one level 
and outline each of the main routines, you will find it 
relatively easy to maintain a coherent program 
structure. You will also find that each routine has 
the same general structure as the other routines. 

Figures 2-1 and 2-2 show what we mean by this. 
Figure 2-1 is a basic top-level flow chart. In this 
minimal form it could apply to almost any program. 
In this case, it is intended for a program that will 
convert a WordStar™ file (or group of files) to ordi- 
nary ASCII text. This is necessary in many cases 


START 


GET REQUIRED 
INPUT 


PROCESS 
THE 
DATA 


OUTPUT 
THE 
RESULTS 


Figure 2-1. A minimum flow chart depicting program 
operation. 
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because WordStar marks the end of each word, 
extra spaces between words (inserted to right- 
justify the text), and certain other characters by 
setting bit 7 of that byte to one. Most print routines, 
unfortunately, won’t clear this bit before outputting 
it (they can’t if they are intended to output any 
graphics characters). Therefore, the last letter of 
each word will look very strange on the screen as 
well as on the printer, and carriage-return/line-feed 
sequences won't perform their proper function. The 
result is a mess both on screen and on paper. 

Figure 2-2 shows a more meaningful flow chart for 
this program. Note that we have made no effort so 
far to determine exactly how each function will be 
performed. There are several ways to accomplish 
this, and we will make that decision at a lower level. 
At this point, we have only defined the basic operat- 
ing procedure. Details will come later. 

Figure 2-3 shows the flow chart for the initial input 
routine. This chart is at one level below Figure 2-2, 
and defines what is expected by the program when 
it is started. Again, the exact text of the error mes- 
sage and the exact means of outputting them are 
not specified; that will be done later. Note also that 
this is only the chart for the GET INPUT PARAM- 
ETERS box in Figure 2-2. The other functional 
boxes are flow-charted separately. 

On this basis, the program designer can work on 
a single task at any one time, and each task is 
relatively small. Therefore, the individual task flow 
chart can be rapidly completed. It will fit on a single 
piece of paper without crowding or confusion, and 
yet it is properly structured and fully informative on 
that level. 
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(START) 


INITIALIZE 
GET INPUT / 
PARAMETERS / 
READ INPUT / 
FILE 


STRIP THE 
CHARACTERS 


WRITE THE 
OUTPUT FILE, 


Figure 2-2. Top-level flow chart for program to convert 
WordStar™ files to plain ASCII. 


Sector 4: Don’t Try To Do It All at Once 


Unless your program is extremely simple and short, 
it will take you a substantial amount of time to 
design it completely, and then more time to code it, 
test it, debug it, etc. There is no need to get it all 
done in one sitting (and usually no possible way to 
do so anyway). 
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ISSUE REQUEST 
FOR INPUT FILE 
NAME 


REQUEST 
OUTPUT 
FILENAME 


ISSUE 
ERROR 
MESSAGE 


ISSUE 
ERROR 
MESSAGE 


ERROR 
? 
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es FIQG™Ure 2-3. The GET INPUT PARAMETERS box expanded from Figure 2-2. 
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For the same reason, if you start to feel frustrated 
because nothing is going right, get away from it for 
awhile! Take your break, and don’t even think about 
the problem itself. Somewhere in the background, 
without any conscious effort or awareness on your 
part, your mind will be working on the problem. 
When you come back to your work, your mind will 
be clearer, and may surprise you by coming up with 
a workable solution to the problem. Very often, 
your mind will be able to solve a problem as a 
“background task” that had it stumped as a “fore- 
ground task.” 

If the problem still has you stuck when you come 
back from your break, break it up again into smaller 
tasks. You can very often solve a problem in pieces 
that defied you as a whole. 

Most people work best for a certain period of 
time, and then need to take a break. Your design 
work on any program should be no exception to 
this. Keep each task or routine block short enough 
so that you can reasonably expect to finish it before 
you need a break. Then, when you do finish it, go 
ahead and take that break. Stand up, go get some- 
thing to drink or eat, walk around alittle, and stretch 
your muscles. This gives your mind a rest from the 
problem at hand, and lets you come back to it 
refreshed and ready to go again. 


Sector 5: Keep Working on the Program Until 
It Is Finished 


This does not mean to work continuously, nor does 


it mean to spend all day every day on the program. 
Take breaks as we discussed above, and work only 
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for whatever time you can properly allocate to the 
task. 

As with study time for a classroom, you should 
set aside a regular space of time every day (or every 
other day, depending on your present schedule). 
Do all that you can to keep that time clear of routine 
commitments and activities; this is the time that you 
will spend working on your program. 

By having a regular time assigned to your pro- 
gram work, you will be assured of having the time 
available. Continue to work regularly on the pro- 
gram until it is completed and debugged. Without 
this scheduling, it is too easy to decide not to work 
on it now, but postpone it until later. Repeated 
postponement leads to not doing it at all, so make 
every effort to set and maintain your schedule. As 
with the tortoise and the hare, slow and steady wins 
the race. 


Sector 6: Using Predefined Algorithms and 
Procedures 


No program is ever designed in a vacuum. Even if 
your program idea is for a task that is absolutely 
new, and which nobody ever thought of before, you 
will be using many techniques, methods, and proce- 
dures that have already been developed for use in 
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other programs. A large number of books have 
been published containing mathematical 
algorithms, workable procedures, and time-tested 
techniques for accomplishing a wide range of tasks. 

It will be well worth your while to acquire a few of 
these publications. The information they contain 
required many man-years of research and devel- 
opment. There is no reason in the world why you 
should have to go over the same ground to get to the 
same result. Why re-invent the wheel? 

Even if you are trying to find a better way to 
perform a given function, you should first be familiar 
with the methods already developed and in use. 
Otherwise, you will be duplicating a lot of effort, 
instead of advancing into new territory. 

If you cannot find a predefined algorithm or 
procedure for a particular task, you will of course 
have to develop one. Once you have done so, you 
should add it to your library of functions and proce- 
dures so that you will have it if you ever need it 
again. 

By maintaining an organized library of all of the 
functions, tasks, and routines you have located or 
developed, you can substantially shorten the design 
process for your new programs. 


Track 2 
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FASTER PROGRAM CODING 


The formal program design procedure calls for 
completing the paper design of the entire program 
before you begin coding. If you are already familiar 
with the coding requirements of a particular func- 
tion, this is still the best way to go. If you are unsure 
of how your design of a particular function will work, 
it may be better to try it out by itself, before incorpo- 
rating it into the program. In this way, you can test 
and debug this individual task before you have to 
check its interactions with other tasks. This can 
help to avoid trips “back to the drawing board.” 

In addition, since compilers and assemblers nor- 
mally either come with, or are used in conjunction 
with, either a text editor or a word processor, a 
number of techniques may be used to simplify the 
process of rendering the paper solution into the 
source code required by the assembler or compiler. 
Let’s see some of those techniques now. 


Sector 1: The Blank Coding Worksheet 


In Module 5, we provided a pad of blank program- 
ming forms. To use such a form, you simply fill in 
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lines of code to match your diagrammed procedure. 
The form helps you to lay out the program code in 
easily followed format, and encourages you to fill in 
at least minimal documentation. 

Such forms are commonly used for small pro- 
gramming tasks and for parts of the debugging 
phase of programming. When you code a larger 
program, however, you will generally find it easier to 
use a text editor program to create your source file. 
In fact, this will be required anyway, if you are going 
to use an assembler or compiler program to gener- 
ate the object code. 

Text editors need not be large or complicated, 
and very often do not qualify as full-blown word 
processors. In the Commodore computers, the 
BASIC. line editor can often be employed to 
advantage, as it is in FAS. In addition, there are a 
number of text editors and word processors which 
speed up their operations by saving all text in screen 
code format, rather than as ASCII code. This 
speeds up the operation of the program by not 
requiring code translation during an edit session. 
Code translation is required for printing, but 
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printers are so much slower than the computer that 
the translation time is not noticeable. 

In assembly language, the source code must often 
be in a single text file. Some assemblers, however 
(such as FAS), allow you to include another source 
file into the assembly process. Either way, it is a 
tedious, time-consuming, and error-prone chore to 
retype a whole list of EQU, or =, directives to define 
special characters, addresses, etc., that you will 
need in virtually every program. To avoid having to 
do this, we suggest that you write a “front end” that 
will be common to all of your assembly language 
programs. This way you can simply load this “front 
end” as the start of any new program you wish to 
write. Or, with FAS, you can simply INCLUDE this 
front-end file at the beginning of each new program. 
Either way, you can proceed to code your program 
directly, without having to first define a lot of 
constants that will usually be needed. 
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If your computer is available at this time, turn it 
on, and LOAD and RUN your FASt assembler 
program (from Module 5). Then, LOAD the file 
ALHEAD.FAS from your Program Disk. This is a 
typical front-end file, set up for use with FAS. Now 
LIST this program and look over its contents. 

In many ways, ALHEAD.FAS is very similar to 
the start of PDSW.FAS, which came with Module 8. 
This is not accidental; we used ALHEAD as the 
starting point for PDSW, just as we suggest that you 
use it or a similar file as the starting point for all of 
your assembly-language programs. In fact, the very 
name ALHEAD is derived from the term “assembly- 
language header.” 

Looking at this file, we find first some comment 
lines to explain the purpose of the file. When you 
begin a program of your own, you should replace 
this text with the name and purpose of your own 
program. 

Next, we find a list of ASCII control characters 
which are commonly used for various purposes. 
You will probably wish to extend this list to fit your 
own requirements. You may need additional char- 
acters, depending on the specific hardware and 
peripheral devices you have and how you intend to 
use them. Do not hesitate to update this list 
whenever you find it desirable or helpful to do so. 

Following the ASCII codes, we find the entry 
addresses of the jump table in the kernal ROM. 
Note that the entries are not listed in either numeric 
order of addresses or in alphabetic order of function 
names but in groups of calls, so that calls will 
normally be made sequentially to the addresses in 
one group. For example, before you can call either 
OPEN or LOAD, you must call both SETLFS and 
SETNAM. Similarly, before you can call GETIN, 
you must call OPEN and then CHKIN. These entry 
addresses are listed in that order. The same is true 
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of the other entries; we have listed them as much as 
possible in the order in which they will be used, 
grouped together to show functional levels. This 
helps you to be sure you call these routines in the 
proper order. 

The FASt assembler does not recognize macros 
as such; but, being essentially an extension of 
Commodore BASIC, it can still use all of BASIC’s 
functions. Some operations are best expressed as 
subroutines, of course; but many simple operations 
can be written in terms of DEF FNx and can then 
use FNx in their program. Some practical FN-type 
functions are listed after the kernal ROM calls. 
Probably the most commonly required ones are 
FNH and FNL, which will return the high-order and 
low-order halves of a 16-bit address or number. 
However, other functions are also quite useful, and 
you may think of others you will wish to add as you 
gain experience. 


Sector 2: “Include” Files 


Blank header files of this type can be used with a 
number of different languages. In addition, some 
text editors and word processors allow you to 
merge one disk file with another or to insert text 
from one file into another at any point. In the latter 
case, there are no line numbers, and text is simply 
inserted at the present cursor location. 

However, Commodore BASIC has no MERGE 
command, and it uses line numbers. You can use 
our “tricky” technique for merging two or more files 
from disk, but you should be extremely careful 


MODULE 9 


about line numbers or the combined program will be 
mixed up or missing some essential code. Fortu- 
nately, many compilers and some assemblers, 
including FAS, permit a useful alternative. 

The C language is deliberately constructed so 
that you can place in any source file a command to 
include another source file in the compiled program. 
The instruction for this is #INCLUDE, and is fol- 
lowed simply by the filename of the source file to be 
included. 

This is primarily done so that the primitive defini- 
tions and memory allocations for a program can be 
placed in a separate “header” file. Then the actual 
program file needs only to have the #INCLUDE 
statement as one of its first lines. For example, a C 
source file named SAMPLE.C would probably con- 
tain the program line: 


#INCLUDE SAMPLE.H 


as one of its first few instructions. The use of a .C 
extension for C source files and the .H extension for 
matching header files is acommon convention in C. 
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There is no reason why you could not use 
#INCLUDE to add more source files to the pro- 
gram. Thus, you could build a library of individual 
routines and functions in C, each with its own 
header file and definitions. Then you could write a 
new program consisting of the main operating rou- 
tine and a number of #INCLUDE statements, each 
of which would add an appropriate functional rou- 
tine to the main program. The only requirement is 
that you be consistent in your declarations of varia- 
ble names, so that the C compiler will not find any 
conflicting definitions. 

Extending this technique, you can even have one 
function #INCLUDE another if needed, so that each 
functional routine need be coded and tested only 
once. 

Most versions of Pascal, including Borland’s 
Turbo Pascal™, also permit you to include one file 
into another. In the case of Turbo Pascal, the 
“include” command is: 


($1 FILENAME.EXT) 


Normally, the extension is .PAS, so that you can 
rapidly identify your source files and keep them 
separate from your object files. 

FORTH uses screens rather than separate files. If 
your applications program extends beyond a single 
1024-byte screen (very common), simply place the 
word: 


a 


near the end of the first screen. This tells FORTH to 
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continue on to the next screen. The final screen 
ends with the word: 


= 


which tells FORTH to go back to wherever it came 
from. This may be the keyboard or some other 
screen. Thus, if your main applications program is 
on screens 20 through 35, but requires a function in 
screen 10 and another one in screen 86, one of the 
screens in the main applications program would 
contain the instructions: 


10 LOAD 
86 LOAD 


FORTH would immediately load these two screens, 
and then continue loading the applications 
program. 

In addition, screen number 86 might well contain 
the instruction: 


75 LOAD 


which would tell FORTH to load screen 75, then 
finish loading screen 86, and then go back to the 
point at which it left off. 

Loading screens in this fashion might well cause 
FORTH to load multiple copies of some screens 
into memory as it interprets or compiles them. You 
still need only one copy of each screen in the file. 
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You can then refer to that screen as often as 
necessary. 


Sector 3: Merging Source Files 


Some text editors can merge source files in mem- 
ory, while others cannot. If yours can do so (or can 
be made to do so ina manner similar to Commodore 
BASIC), you may well wish to combine individual 
files in this manner, so that you will have a single, 
final source file to assemble or compile. If a 
particular assembler cannot handle multiple files or 
included files, then it will be necessary to combine 
them into a single file. One problem with this is the 
memory limit. For example, FAS requires that its 
main file be loaded into memory before it is 
assembled. Many other assemblers and compilers 
have a similar requirement. However, the available 
user memory in a Commodore 64 is quite limited, 
and the memory in a C128 is not much less limited. 
If the entire source file must be in memory at one 
time, it must be severely restricted in size, as must 
the resulting assembled or compiled program. 

Fortunately, it is not actually necessary to have 
the complete source code in memory all at once. It 
is quite possible for an assembler or compiler to 
scan the source code from disk instead, reading in 
only one line at a time, keeping in memory only the 
current line, the symbol table, and the output code 
as it is generated. The output code can also be 
written to disk, thus leaving that much more space 
for the assembler or compiler and the symbol table. 
FAS will not do this with the main source file, but it 
will with included files. 
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How do we deal with an assembler program that 
will operate this way, but will not accept included 
files? How can we combine several different source 
files, each of which will fit into memory by itself, into 
a single, large source file that will not fit into 
memory? The solution is to combine the individual 
files into a single file, by a process of concatenation. 
Basically, this requires a means of reading each of 
the source files in turn, one line at a time, and writing 
all of these lines to a single destination file. 

Fortunately, with FAS we do not require such a 
technique. However, with some assemblers and 
compilers, and with some types of computers, it is 
necessary to copy all of the source code together 
into a single file, in order to assemble it as a whole. 

There is one possible problem with this approach: 
once you have combined all of the source files for 
assembly, you will probably be unable to fit the 
combined file into memory for further editing. 
Therefore, you should keep the individual files on 
hand for editing and corrections. Once you have 
edited all files, you can combine them again for 
reassembly. 
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CODING FOR EFFICIENT EXECUTION 


As you have already learned, there are many differ- 
ent solutions to any given problem. Some solutions 
are more complicated than others, while the simpler 
ones may not be sufficiently complete for all 
applications. 

One of the primary reasons for the initial design 
procedures for any program is to make sure that 
you have completely stated the problem and that 
you have determined all of the required solution 
factors. Most people find the coding process far 
more interesting than the paper design procedure. 
However, they also learn quickly that efficient cod- 
ing is not possible unless, and until, the groundwork 
has been laid and the preliminary operations are 
complete. 

When you have completed the initial design of the 
program, you will find that you still have a wide 
range of options for coding the program. For exam- 
ple, program loops and conditional operations can 
be specified in several different ways. All of the 
different ways will work correctly, but each method 
has advantages (and disadvantages) compared to 
the others. Each technique was developed to work 
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best under specific conditions. Therefore, you 
should always look for the technique that will be 
most efficient and effective in your particular applica- 
tion. 


Sector 1: Conditional Execution 


One of the most common requirements in almost 
any program is to make a decision. The action taken 
by the program then depends on the result of that 
decision. Thus, the actual sequence of instructions 
executed by the program will depend on the condi- 
tions encountered by the program. This is what we 
call conditional execution. 

As you already know, there are many possible 
conditions that can be examined and many ways of 
selecting which instruction is to be executed next, 
according to the selected condition. How can we 
arrange our program code to minimize the number 
of jumps that must be made to accomplish this? 

As a simple example, consider a situation where 
we have the integers X and Y. If X=0, we must add 1 
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to the value of Y. In BASIC, we might do this with 
any of the following command sequences: 


IF X=0 THEN Y=Y+1 


IF X=0 THEN GOSUB 1000 


1000 Y=Y+1 
1010 RETURN 


IF X< >0 THEN 450 
Y=Y+1 
450 


In this case, the first choice is the simplest. This is 
because only one instruction needs to be executed 
if X=0, or bypassed if X is not 0. Thus, the entire 
decision, complete with the action to be taken ona 
conditional basis, will fit easily on a single program 
line. 

If the conditional action consisted of several 
dozen instructions, the third choice would be pre- 
ferred. Depending on the complexity of the instruc- 
tions to be executed, we might be able to separate 


them with colons and put them all on the same line 
with the IF statement, thus returning to the first 
structure. This is not always a good idea, however, 
since such a command line is hard to read. It is too 
easy to make a syntax error of some sort, and too 
hard to find it in this type of construction. 

The second construction given should be used 
rarely. If the conditional sequence of instructions is 
properly defined as a subroutine required by the 
program at a number of different times, then this 
construction is proper. Otherwise, this construc- 
tion is more complex than it needs to be, and is 
therefore not generally preferred. 

In assembly language, it is impossible to concat- 
enate the instructions following a test. All condi- 
tional instructions are jumps of some kind. They 
come in complementary pairs; that is, each condi- 
tional test is also available as exactly the opposite 
test. Thus, the 6502 microprocessor family has a 
BEQ (branch if equal) instruction and a BNE 
(branch if not equal) instruction. All of the condi- 
tional branches are paired in this manner. 

Now, if we have a sequence of instructions that 
may or may not be executed (according to the 
results of a test), the easiest approach is usually to 
code the instructions in line, as if they were to be 
executed, and then arrange the test and conditional 
branch so that these instructions will be bypassed if 
necessary. For the example we used in BASIC, if we 
let X reside in register A and Y in register Y, the 
instruction sequence might be as shown below. 


CMP #0 
BNE GO—ON 
INY 


GO—ON: 


;Does accumulator contain zero? 
;If not, bypass the INY instruction. 


;Continue from here. 
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This corresponds to the third sequence we 
showed for BASIC. This is necessary because we 
can specify only one thing at a time in assembly 
language. 

Most high-level compiled languages do not allow 
you to decide the structure of the final code. For 
example, both C and Pascal allow you to define a 
block of code of any size you need following an IF 
statement, but then the compiler decides how the 
final machine code will be structured. FORTRAN, 
being an early, unstructured language, allows you to 
define the structure of the program, but limits you to 
one instruction per line, as does assembly language. 
Therefore, the most efficient approach is to code 
the conditional sequence in line and use the condi- 
tional jump to go around it if necessary. 

Conditional structures can be extended to much 
greater complexity. Most languages permit an 
ELSE clause to be added to the IF ... THEN struc- 
ture. It is also possible to add more conditions in the 
form of a CASE statement. In the CASE statement, 
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a single variable is compared with a list of possible 
values. When a match is found, the appropriate 
sequence of instructions is executed. 

BASIC supports a limited CASE statement in the 
form of the ON...GOTO statement. In assembly 
language, you can implement a CASE structure 
using the format shown in Figure 4-1. Most modern 
languages include some kind of CASE statement. 
However, if no other option is available, you can use 
the structure: 


Pick 
THEN ... 
ELSEIF: «2. 
THEN a0. 
28 S| ae 
THEN .3< 
ES oS | es 


THEN...» 


and so on. This is a clumsy construction, but it will 
work in the absence of other possibilities. 

Whenever you place a decision into your pro- 
gram, be very careful how you implement it. Deci- 
sions can be very time-consuming, especially in 
high-level languages. This is because a decision is 
based upon the results of one or more tests. There- 
fore, the tests must be performed, and then the 
actual conditional jump performed in accordance 
with the result. 
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FIRST: CMP #CHARI 3DO WE MATCH THE FIRST CHARACTER? 
BNE SECOND sIF NOT, CHECK THE SECOND 
. ;FERFORM APPROPRIATE ACTIONS FOR 
. ; THE FIRST CHARACTER, 
JMF DONE STHEN EXE 
3 
SECOND: CMP #CHAR2 DO WE MATCH THE SECOND CHARACTER? 
BNE THIRD ;IF NOT, SKIP ON 
JMF DONE SEXIT 
: 
THIRD: CMF #CHARZ s THIRD CHARACTER MATCH? 


BNE FOURTH 


JMF DONE 
3 
FOURTH: CMF #CHAR4 ;FOURTH CHARACTER MATCH? 
BNE OTHER 3; IF NOT, NO CASE MATCHES 
JMF DONE sEXIT 
3 
OTHER: . sEITHER OUTFUT ERROR MESSAGE 
. ;0R TAKE DEFAULT ACTION WHEN 
. 3;NO MATCH OCCURS 
DONE: . sFINAL EXIT FOR THE WHOLE ROUTINE 


Ina CASE structure, a series of comparisons will 
be made until a match is found. Each comparison 
consists of one or more tests followed by a condi- 
tional jump. If a match is found at the first test, no 
other tests will be made. However, if a match is 
found only by the last test, all previous tests will be 
performed first, and all conditional jumps will be 
taken to bypass the previous blocks of code. 

Because of this, it is worthwhile to limit the 
number of actual tests that must be made to deter- 
mine whether or not a particular block of code must 
be executed or bypassed. In addition, if you have a 
CASE structure, place the most likely match first in 
the sequence of comparisons, the next most likely 
match second, and so on. Thus, the most common 
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Figure 4-1. A four-case structure in assembly lanquage. 


match will be found as quickly as possible, and 
slightly less likely matches will be found almost as 
quickly. Those matches that take longest to find will 
be least likely to be used. 

If you don’t observe this rule, you may well find 
that the most commonly required code blocks will 
take longest to find and execute. It will look the 
same in a flow chart, but can nevertheless slow 
down the effective execution rate of the program. 


Sector 2: Program Loops and Subroutines 


Program loops may be constructed in a number of 
different ways. When you design and code a 
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program loop of any type, compare the execution 
times of different types of loops. Run tests, if neces- 
sary, to make sure that the loop runs efficiently. 
This is especially true for loops that will be executed 
often, and in which no operator input will be 
required. 

The point here is that the instructions inside a 
program loop will be executed some number of 
times. Therefore, any inefficiency inside the loop will 
be multiplied by the number of times the loop is 
executed. Even an extra loss of, for example, 10 
microseconds for each pass through the loop can be 
costly. If the loop is executed 100 times, the total 
inefficiency adds up to a loss of a full millisecond. 
That’s a long time to a computer, and it gets worse 
as the loop is repeated more often. 

If the loop is waiting for operator input, the prima- 
ry delay will be from the operator, rather than in the 
loop itself. Therefore, such program loops often 
need not be optimized for execution time. 

In addition, it is more important that a loop be 
optimized if it will be executed many times. A pro- 
gram loop that will be executed only a few times, 
perhaps during the initialization phase of the pro- 
gram, will not cause a great deal of delay even if it is 
not optimized. On the other hand, aloop in the main 
body of the program, which may be reached and 
repeated any number of times during the execution 
of the entire program, can really hurt program exe- 
cution if it is not optimized. 

For example, the FORTH language is designed as 
“indirect threaded code.” This means that each 
high-level word consists of nothing more than a 
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series of addresses, each of which points to other 
addresses, which in turn point to the actual machine 
code to be executed. Low-level words are actual 
machine code. In each case, however, the machine 
code to be executed always ends with a routine 
called NEXT. This is the routine that causes 
FORTH to advance to the next word in sequence, 
to be executed. 

Since NEXT ends each and every word in the 
FORTH dictionary, it appears many times through- 
out the dictionary. Also, it will be executed many 
times, even in the execution ofa single word. During 
the execution of an applications program, NEXT 
will be executed millions of times, and perhaps bil- 
lions of times. 

FORTH cannot be implemented efficiently on the 
6502 microprocessor, because the 6502 cannot 
handle 16-bit numbers directly. Therefore, we will 
use the IBM PC and the 8088 microprocessor for 
this example. In all FORTH programs, the routine 
NEXT is being executed constantly, so it is always 
optimized to the greatest possible extent. 

The function of NEXT is to complete the execu- 
tion of one word and go on to the next one. Thus, 
NEXT must advance FORTH’s Instruction Pointer, 
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get the address of the machine code to be executed 
next, and transfer control to that block of code. 
There are, of course, many ways in which this can 
be done. Using an 8086 or 8088 microprocessor, we 
can choose which register we want to use for 
FORTH’s Instruction Pointer. Let’s see how we can 
accomplish the function of NEXT, and how long it 
will take to perform the task. 

Suppose we use BX as the IP (Instruction Point- 
er) for FORTH. Then, we might use DI to hold the 
address pointer. The resulting code sequence 
would be: 


MOV  DI,[BX] ;Get address pointer. 

INC BX ;Advance IP for next time. 
INC BX 

JMP_ [DI] ;Go execute the code. 


By using either BX, SI, or DI as the IP and another 
of these registers as the holder of the current 
address pointer, we can use indirect addressing and 
directly jump to the code to be executed. Other- 
wise, the code would become more complicated. 

If we determine the number of clock cycles 
required for the above routine, we find that it 
requires 17+ 2+2+11=32 clock cycles. Can we do 
better? 

As it turns out, we can improve this time. If we try 
other registers as the IP, we will eventually get 
around to using SI for this purpose. This should lead 
us in turn to the use of the string instruction, LODS. 
This instruction has the advantage of performing 
the INC operations automatically as it performs the 
MOV. It does require that the operand go into AX, 
so we will have to move it to BX before we can 
perform the JMP, but this may still save us some 
time. The new code sequence is: 


LODSW ;Get the pointer into AX. 
MOV BX,AX ;Move it to BX. 
JMP [BX] ;Go execute the code. 


Now, the time required to execute this code is 
16 + 2 + 11 = 29 clock cycles. This is a savings of 3 
clock cycles, or (with a 4.77 MHz clock) approxi- 
mately 0.625 microsecond. This may not seem like 
much; you could never detect such a difference on 
your own. However, keep in mind that each and 
every word in the entire FORTH dictionary ends, 
one way or another, with NEXT. If each new word 
contains an average of 10 other words in its defini- 
tion, this means that NEXT will be executed 10 
times during the course of executing that single 
word, and an 11th time to leave that word. In addi- 
tion, most of the words in the definition will also be 
high-level words that will also contain around 10 
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words each in their definitions. Thus, NEXT will be 


executed about 100 times at the second level, 10 
times at the first level, and once at the top level. 

Now, assume that word definitions nest to an 
average depth of 6 levels. That is, FORTH will 
thread through six levels of compiled words before 
reaching any actual machine code. This means that 
NEXT will be executed a whopping 1,111,111 times 
during the execution of just one of your application 
words. Thus, a savings of 0.625 us per execution 
translates to a savings of almost 0.7 second for each 
of your application words. As your application pro- 
grams become more complex, the savings pyramid 
rapidly along the same lines. 

The same kind of logic holds true for subroutines 
that are used commonly. Your program can save 
significant amounts of time if you design the subrou- 
tine to be as efficient as possible. The more often 
any block of code is used during a program, the 
more time you can save or lose, depending on how 
you code it. 

On the other hand, even substantial time savings 
in a block of code used only once will have little 
effect on the overall execution time of the program. 
Therefore, to make your programs more efficient, 
examine first those program loops, macros, and 
subroutines that are used frequently. 

In older computers with very restricted amounts 
of memory, it was often important to find the means 
of coding a program using the least possible number 
of bytes of code. If time were also important, such as 
in a real-time application, some compromises had to 
be made between memory usage and execution 
time. Newer computers have far greater memory 
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capacity, however, so the restriction of memory 
usage does not apply to the same extent. 

As you code a program, keep in mind that the 
need for efficiency in terms of either time or memory 
usage will depend on the application. Some pro- 
grams, especially very small ones, will not be notice- 
ably affected by less than completely efficient code. 
More complex programs call for greater care in 
design and coding. In addition, some types of pro- 
grams, such as high-speed communications 
programs, demand the greatest possible efficiency 
just so they can keep up with the data they are 
transmitting or receiving. 


Sector 3: How To Design Efficiency into Your 


Code 


It is not always easy to design your code as effi- 
ciently as possible. In some cases, especially with 


- small programs, efficiency is unimportant, and the 


program completes its run in very little time anyway. 
As a program becomes larger or more complex, 
however, efficient code becomes more and more 
desirable. 

Early high-level compilers, such as FORTRAN 
and COBOL, made little or no effort to produce 
efficient code. It was enough that the program ran at 
all. The time saved in actually writing the program in 
a high-level language was considerably greater than 
the time lost during execution. 

Modern programs have more stringent demands 
on them. Many of them must operate in real time, 
despite the fact that they must perform far more 
tasks, and behave to some degree in an intelligent 
manner. Indeed, Artificial Intelligence is a brand 
new and extremely important field of endeavor in 
programming. 
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It has long been accepted that assembly language 
is the only way to obtain the greatest possible 
degree of efficiency from your program code. This is 
because compilers had to allow for every possible 
variation in such matters as decisions and loops. 
FORTRAN compilers, for example, followed every 
comparison with three conditional jumps corre- 
sponding to “less than,” “equal to,” and “greater 
than.” All three jumps were always coded, even if 
two of them simply fell through to the very next line 
of code (which was very often the case). 

Newer compilers are better designed, and do 
attempt to produce optimized object code. They 
aren’t perfect, but they are far better than they once 
were. Nevertheless, for maximum possible effi- 
ciency, you must work, at least partly, in assembly 
language. 

Fortunately, you need not necessarily do all of 
your work in assembly language; many modern 
compilers include methods for incorporating 
assembly-language routines in their compiled code. 
Thus, you could design and code any critical rou- 
tines in assembly language, and write the rest as 
compiler source code in your selected language. 

Another approach is to have your compiler write 
its output as assembly-language source code rather 
than as object code. At least one C compiler, made 
available under the name Small-C on a Shareware 
basis, works this way. Using this technique, you can 
write your program entirely in C, compile the pro- 
gram, and then check the resulting assembly- 
language source code. The compiler will even copy 
your comments and labels to the assembly- 
language source code. Then, you can proceed to 


optimize the assembly-language source code with- 
out having to actually code the program in assembly 
language. 

Regardless of the approach you use, it is the 
design and development of the critical blocks of 
code that can speed up or slow down your program. 
It is these blocks of code that you must identify and 
optimize in any application that may require such 
care. 

We have already pointed out the kinds of code 
blocks to look for when you seek to optimize your 
code. Basically, these are conditional operations, 
program loops, macros, and any segment of code 
that is executed many times. Once you have identi- 
fied such blocks of code, you can start optimizing 
them. 

As we mentioned earlier, the key to optimizing 
conditional blocks of code is in organizing that code 
within the program. Thus, code that might or might 
not be executed should normally be coded in line, 
with a conditional jump to bypass it if necessary. 
Thus, only one test or series of tests will be required, 
and only one jump instruction (the conditional one) 
will be encountered. 

In the case of multiple comparisons of which only 
one will actually produce a match (the CASE struc- 
ture), if possible you should place the most likely 
comparisons first, so that they will be found early. 
The less common comparisons can come later, 
since the added delay of making all of those extra 
comparisons will not be encountered as often. 

In many cases, you can find ways to calculate 
rather than compare. This is because many micro- 
processors, including the 8086 series, require a large 
number of clock cycles to perform a relative jump or 
branch. This is not true of the 6502, where a 
conditional branch can be taken in either three or 
four clock cycles (depending on whether or not the 
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branch would thereby cross a page boundary) or 
else can fall through in only two cycles. Because the 
8086/8088 microprocessors have a much greater 
difference between time required to take or fall 
through a conditional branch, we will use this 
microprocessor to illustrate our point. 

A common requirement for outputting data is to 
convert a 4-bit binary number to ASCII, to be output 
as a hexadecimal character. The traditional ap- 
proach is to add 30H (the ASCII bias for numeric 
digits), compare the result with 39H (digit 9), and 
then add 7 if necessary to produce a letter A through 
F. In 8088 assembly language the code is: 


AND AL,0OFH 34 cycles 
ADD AL,90H ;4 cycles 
DAA ;4 cycles 
ADC AL,40H :4 cycles 
DAA 34 cycles 
RET 38 cycles 


The 6502 does not have a DAA instruction but 
will perform decimal arithmetic if you use the SED 
instruction. Either approach will require 17 or 18 
clock cycles in the 6502. However, the point is still 
valid: in program loops and repeatedly executed 
blocks of code, check your code carefully using a 
number of different organizations. Then you can 
optimize these often-used blocks of code and select 
the precise method that will execute most effi- 
ciently. 
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Use NRIBUG or a similar debugger to try out 
different versions of code, to make sure that they all 
work correctly. Also, try to simplify the code as 
much as possible. The fewer instructions you use, 
the easier it will be for you to test that code, and the 
faster the computer will execute it. Always use the 
simplest possible code that will do the job. As you 
practice this, you will find yourself rapidly gaining 
proficiency. 
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FASTER PROGRAM TESTING 


AND DEBUGGING 


Once a program has been compiled or assembled 
with no error messages, this still does not guarantee 
that it will run as intended in all ways. The program 
must be tested in all of its functions, as well as the 
interactions between functions. However, if you use 
the various procedures we have already discussed 
in earlier tracks, and if you do some careful thinking 
as you do your testing, you can eliminate a substan- 
tial part of the testing without any risks. You can 
similarly avoid the need for debugging much of your 
code. 

In part, the testing and debugging process is 
made simpler by using pre-tested and pre-debugged 
code in your program. After all, you need not test 
what already works correctly. However, there are 
also procedures that you can follow while testing 
and debugging, to speed up the debugging process 
even for modules that have not yet been tested. 
Let’s see how we can speed up the debugging pro- 
cess, both before and during the actual testing and 
debugging procedures. 
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Sector 1: Using the Software Library — 
Assembly Language 


As we mentioned earlier, it is very useful to build up 
and expand a software library which includes not 
only complete programs but also functional blocks. 
These blocks may be written in either source code 
or object code, depending on how they were origi- 
nally coded and how they will be used. 

When you originally design a functional block of 
code, you should test and debug it extensively. 
Then, you can save it as either source or object 
code (or both), for use in any desired programs. 
Having done so, you will not need to test the inter- 
nal operation of that block of code, since you 
already know it will work correctly. You will still 
have to make sure that the predefined block of code 
will interface correctly with the rest of the program. 

If you are working in assembly language, you have 
two possible ways to go. The first possibility is to 
preassemble each code module and assign it its own 
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address in memory. In the Commodore computers, 
this is unsatisfactory because each module would 
have to be assigned a different memory location, 
making it unable to overlap the space reserved for 
other modules. Also, the C64 and C128 do not have 
a lot of memory to spare. 

It is possible to have a “relocating loader,” which 
will take a list of individual assembled modules, load 
them into successive segments of memory, and 
modify all references to each other and to absolute 
memory locations, so that the modules can work 
together. 

The alternative is to keep all of your program 
modules as source files on disk. Then you can use 
the “include” directive to incorporate a given 
module into another program. This tells the as- 
sembler to stop assembling the current file and start 
assembling the specified file from disk instead, until 
it is done. Then it will resume assembly of the 
original source file, immediately following the “in- 
clude” directive. 

Of course, with an assembler that does not 
recognize the “include” directive, you would have to 
combine all of the source files into one or else 
assemble each file separately. In the latter case, you 
can include the important addresses in each source 
file as a set of equates in the other files. 

Regardless of how you assemble your program, 
the result will be an executable program which you 
can proceed to test and debug as necessary. During 
the testing process, you can concentrate on those 
blocks of code that were not part of your software 
library, since those blocks of code that are in your 
library have already been debugged. 


The first step, as with debugging any program, is 
to load NRIBUG or an equivalent program and then 
load your new program under NRIBUG. Now, 
before doing anything else, remove all floppy disks 
from their drives and, if possible, make sure that any 
hard drive or other peripheral device will not be 
adversely affected by your program. If the program 
uses disk files, use a scratch disk and backup copies 
that can safely be scrambled or erased, in case of a 
problem with your program. 

Now try executing the entire program, just to see 
what will happen. If the program works, you will 
know at once that little or no debugging will be 
required. However, you should still check it out 
carefully if there is any possibility whatsoever that 
any part of the program did not get exercised. In the 
likely event that the program does not perform 
perfectly, you may get some idea, from the displays 
it generates, of just how far the program got before 
it had a problem. 

Next, go through the program step by step. As 
you do, you should be able to recognize those 
blocks of code that come from your debugged 
software library. These blocks of code can be almost 
totally bypassed. To stop execution and verify that 
the code has indeed produced the correct results in 
terms of register contents, memory contents, and 
condition flags, you only need to insert a breakpoint 
at the end of the code block. The idea is to make 
sure that the predefined block of code interfaces 
correctly with the rest of the program. If it does, you 
will not need to troubleshoot the block itself. 

In addition, if you locate key points in your 
program, you can execute blocks of code at a time, 
even in your new code. Since you have already run 
the complete program and observed its action, you 
can make an educated guess as to where the 
problems causing the program to do the wrong 
thing were. You can use your assembly-language 
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listing to help you find that location in the program. 
Then, use NRIBUG to insert a breakpoint imme- 
diately before the suspect block of code. You can 
then trace through that block, one instruction at a 
time, to find the actual problem. 

In fact, sometimes you can locate a problem just 
by going through the program source listing. This is 
especially true if you have included appropriate 
comments throughout the listing. Using this 
method, you can scan through the source listing 
while analyzing the action of the program as written. 
Compare what the program is actually doing (from 
both the actual run and your analysis) with what you 
wanted the program to do. Many problems can be 
picked out and clearly identified this way, without 
the need to use NRIBUG or any other utility. 

In any case, use NRIBUG to execute your 
program in functional blocks, rather than one 
instruction at a time. When you reach the end of a 
block with incorrect register values, you can trace 
through the block by individual instructions and 
determine exactly what caused the incorrect re- 
sults. 

If you can use NRIBUG to patch the code at 
once, do so. Make note of the change you have 
made and then try that block of code again. Once 
you have that block of code working correctly, 
continue debugging block by block as before. If you 
cannot patch the code directly, use NRIBUG to 
modify registers or memory locations as needed to 
simulate the missing instructions. Then continue 
with your debugging procedures. 
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Once you have made sure that your corrections 
will make the program work properly, go back, 
correct your source code, and reassemble. Your 
program should work correctly straight from the 
assembler before you leave the program. At this 
point, you can add it to your software library. 


Sector 2: Using the Software Library — High- 
Level Languages 


Debugging compiled programs is less straightfor- 
ward than debugging assembly-language programs, 
because of the way in which a compiler must 
operate to ensure that all contingencies are met. 
Some of the newer compilers attempt to optimize 
the object code, but they are still less than perfect. 
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Older compilers do not optimize their output code 
and are even harder to follow. You have already had 
a small taste of this in an earlier module, with a 
compiled BASIC program (“Hello, World!”). A 
program of this size is best written in assembly 
language, since it is so short that it doesn’t take 
much more time to write the assembly-language 
source code than to write the high-level source 
code. However, longer programs can be coded 
much more quickly in high-level languages than in 
assembly language. Therefore, large programs are 
generally written in compiler languages, and the 
extra overhead of the run-time package is accepted 
as the lesser of two evils. 

Testing and debugging such long programs can 
be more difficult in some ways because a large 
portion of a compiled program is likely to consist of 
subroutine calls to various run-time subroutines, 
along with embedded data. How can you correlate 
this with your source code? 

Fortunately, there is a simple trick you can use to 
allow the program itself to provide some visual 
displays to describe its own operation. This will 
work nicely in any compiled program and can be 
removed easily when debugging is complete. As you 
code your program, include some PRINT com- 
mands (or their equivalent in any selected language) 
at the end of each functional block, to display a brief 
statement on the screen. It will help if your program 
is display oriented and cannot be disturbed in this 
respect. In such a case, you can have the status 
reports output to the printer instead. 

Either way, you can directly observe the progress 
of your program as you follow the displayed or 


printed messages. As any problem appears, you can 
immediately determine which message was given 
just before the problem was encountered. In this 
way, you know at once that the problem appeared 
between two specific messages, which you can 
quickly locate in your source code. 

If you wish to use NRIBUG or another debugging 
program to examine the compiled object code, you 
can use these messages to guide you through the 
program. The text will appear as individual charac- 
ter strings, each following a JSR instruction or 
another standard set of instructions, depending on 
the language and the compiler. JSR instructions will 
be most common; however, except for modifying a 
character string for test purposes, we strongly urge 
that you do not attempt to modify a compiled 
program of this type directly. Unless you clearly 
understand exactly what the program is doing with 
all of these JSR instructions, there is too much 
chance that you will cause more problems than you 
will solve by direct modification. 

Some compilers, notably those using the C 
language, tend to produce object code that more 
closely resembles the source program and that you 
might have assembled rather than compiled. In fact, 
one Shareware C compiler is deliberately geared to 
produce assembly-language source code rather 
than object code. This allows the programmer to 
write the program in a high-level language and then 
“fine tune” it before generating the final object code. 

Of course, there is still some code added by the 
compiler, but this is in accordance with programmer 
directives rather than an automatic insertion. For 
example, most C programs will include the direc- 
tive: 


#include “stdio.h” 


This tells the compiler to incorporate the stan- 
dard input/output package into the object code. 


MODULE 9 


Tools and Tricks for Program Design 


You will rapidly get to know this block of code if you 
try debugging compiled C programs directly. Other 
run-time packages are generally written as applica- 
tions in C source code, which you should have in 
your C software library and which you can include in 
your programs whenever you may need them. 

In any event, you can still place small comments 
at the end of each functional block of your program, 
to be printed or displayed as appropriate, which will 
permit you to trace through the actual execution of 
your program. In addition, you may be able to use 
NRIBUG to examine and patch the object code, if 
the compiler produces fairly direct object code from 
the source code, rather than a long list of JSR 
instructions. 

Regardless of the language used, once you have 
successfully debugged your program and have it 
working correctly, you can simply remove your 
“progress reports” from the source code and 
recompile without these comments. The result 
should be a working program. 


Sector 3: Segmenting the Program 


One of the main concerns of any program trouble- 
shooter is that a large program can seem over- 
whelming, especially when you first try to debug it. 
As you gain experience in writing and debugging 
programs, you will find this feeling diminishing, but 
very few programmers can claim that it goes away 
entirely. 

Fortunately, there is an alternative technique 
that can be used to reduce the program to a size 
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that is not so intimidating. This technique may go by 
any number of names, but we will call it segmenta- 
tion. By this we mean that a program does not have 
to be handled as a single entity except for the final 
tests. Before that, there is no reason not to test 
each functional block separately. In fact, in many 
cases you might wish to design, test, and debug 
individual program blocks or functions, and add 
them to your program library in this manner. Then, 
the final program testing is only required to make 
sure that the different modules work together 
correctly. 

To take advantage of this technique, first go 
through the basic design procedure for the entire 
program. You can include existing modules from 
your software library, but do not attempt to design 
new modules for the library at this time. Once you 
have completed the paper design for the program, 
you are ready to begin coding. At this point, you 
may be totally sure about some parts of the pro- 
gram, but not really certain about other parts. The 
parts that you understand clearly and have no prob- 
lems with may be coded directly and immediately 
made part of the program. However, you can help 
save substantial time in later debugging if you take a 
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little time now to work with any uncertain program 
behavior. 

Any time you are not sure of how to code a 
particular program function or behavior, try coding 
it separately on paper and then key it into the 
computer using NRIBUG or a similar utility. Trace 
through it, try it several different ways, and find out 
whether or not it performs as desired. If so, go ahead 
and add it to your program code. If not, “play” with 
it and adjust it until it performs as intended. Then 
you can add the corrected source code to your 
program. In the case of a compiler language, 
compile that block of code alone, together with any 
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data (expressed as constants for the moment) 
required to demonstrate the operation of that block 
of code. 

In this way, you can work with small pieces of 
code rather than large ones, and gain substantial 
practical experience at the same time. Each time 
you work with even a small block of code in this 
fashion, you will gain a clearer and surer under- 
standing of how the computer works. You will also 
more clearly understand how the microprocessor, 
doing nothing more than manipulating binary Os 
and ls, can nevertheless be programmed to per- 
form such a wide range of real-life, practical tasks. 

Once you have cleared up any problems or ques- 
tions with individual code blocks, you can proceed 
to complete the full program code, and assemble or 
compile it as appropriate. Since you will have 
already cleared up any problems or uncertainties 
you had with your code, you should have very little 
debugging left to do on the overall program. 
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SOLUTIONS AND NEW PROBLEMS 


As always, practice makes perfect. This is just as 
true in programming as in any other subject. One 
good thing about the use of these techniques to 
speed up your program generation, however, is that 
you need not apply all of them at once, nor do you 
have to apply any of them that you don’t feel com- 
fortable with. Instead, you can pick any technique 
that you like, and start working with it. As you gain 
experience and confidence, you can extend that 
technique in any way that fits your own program- 
ming style. Then, you can add other techniques as 
you wish. 

The use of various programming tools is a highly 
individual thing. As you try various methods, you 
will find that some appeal to you while others don’t. 
In addition, other ideas will occur to you, and you 
will find yourself trying other techniques that work 
well for you, even if they don’t work for anyone else. 
The only thing you need to start with is a little 
practice with the techniques we have already 
covered. 

As usual, we will first look at the problems we 
posed in the previous module. Then, we will go on 
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to some problems designed to help sharpen the 
skills you learned in this module. 


Sector 1: Converting PDSW.COM for use on 
the Commodore 


The conversion of PDSW.COM from IBM assembly 
language to Commodore assembly language is 
somewhat tedious but entirely straightforward. The 
basic requirements of the program are: 


1. Initialize the printer to the proper line-feed size 
and mode. 

2. Open the text file and read the first 48 lines of text 
into memory. 

3. Locate the graphics codes for the first character 
on the 48th line and output these codes to the 
printer. 

4. Repeat Step 3 for the first character on lines 47 
through 1, backwards from 47. 

5. Repeat Steps 3 and 4 for the second, third, etc. 
characters on all lines. 
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6. Issue a form-feed character. 

7. If there is more text in the file, read the next 48 
lines and go back to Step 3. 

8. When the end of file has been reached and all 
lines output, close the file and reset the printer. 


This is the process performed by the IBM version 
of the program. To use it here, we must rewrite the 
program in 6502 assembly language. Fortunately, 
except for differences in procedure required by the 
different operating systems, this is not a difficult 
task. 

One of the choices we must make at once is 
whether our converted sideways printer program 
should handle the Commodore graphics characters 
or upper-case and lower-case letters. Since the 
graphics characters would normally be used to 
reproduce screen images, which will not normally 
have to be printed in sideways format, we have 
chosen to output upper- and lower-case letters, 
using the ASCII code as our pattern. This also has 
the advantage of allowing us to use the same 
graphics bit patterns as the IBM version, provided 
we write our program for a similar printer type. 

The completed PDSW.FAS program is on your 
Program Disk. If your computer is available at this 
time, turn it on, then LOAD and RUN FAS, if the 
assembler is not already present in memory. Now 
LOAD the file PDSW.FAS from your Program Disk 
and begin to LIST it. Remember that under FAS you 
can pause the listing by pressing any key. If you use 
a function key such as F7, no characters will appear 
in the keyboard buffer at the end of the listing. 
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We start with the same constants and functions 
that we used before, since they define the access 
addresses to the Kernal ROM routines. There is one 
crucial difference near the start: the IBM version of 
the program expected the name of the file to be 
output as part of its command input line. We cannot 
do this with the Commodore computers, so instead 
we must request the name of the file after the 
program has started. Once we have the file name, 
we can open it as an input file only and open the 
printer as an output device only. This is important: 
we can have both the disk file and the printer open 
simultaneously, because there is no conflict be- 
tween reading and writing. When we write charac- 
ters to the printer, they will also go to any open 
output file on the serial bus. Therefore, we make 
sure there is only one output device open at a time. 
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Similarly, we should only accept input from one 
source at a time, to avoid any confusion. 

Once we have the filename of the ASCII text file 
to be printed out, we can directly convert the 
remainder of the IBM program to Commodore 
(6502) mnemonics. In so doing, however, we have 
used a few useful techniques to save memory space. 
As you LIST your copy of the program, look for 
these techniques. 

First, we identified two groups of character 
strings. Any strings that are required only at the 
start of the program we placed at the very end of the 
program. This includes the name of the file to be 
printed in sideways format. Character strings take 
up a lot of space, so we will allow the ASCII text file 
to overwrite any that we will not need past the very 
start of the program. The largest such string is the 
“banner,” or startup message printed out by the 
program. Even if we wish to output multiple files, this 
message will only be printed once. 

Other character strings, such as error messages, 
progress reports, etc., will be required at any time 
during the execution of the program, so these will 
not be overwritten. 

The remaining question concerns the acceptable 
maximum line length in the Commodore version. 
We should keep the 48-line arrangement, since 48 
lines will readily fit the 8-inch width of the page. 
However, a line length of 1024 characters is 
impossible, since we do not have 48k of RAM 
available to hold those lines. We do have over 38k 
available, and the program will not be exceptionally 
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large. Therefore, let us allocate 24k as the text 
buffer, giving us a maximum line length of 512 
characters. This should be satisfactory for our 
purposes. 

The remainder of the conversion proceeds di- 
rectly. We suggest that you compare your program 
conversion with ours and compare both with the 
original IBM source listing. As you compare them, 
keep in mind that there is no one “right” way to 
perform this conversion; if your program works 
correctly, then it is “right.” 


Sector 2: The TYPE program 


The TYPE program provided in your previous 
module worked, but in a very limited fashion. Since 
it was written in BASIC without any special pre- 
cautions, it does not echo commas or semicolons 
but takes these (as well as carriage returns) as 
markers to end a character string. 

Another problem is that TYPE will permit an 
entire text file to scroll by, without stopping the 
display to allow time to read it. This is a serious 
problem. We can use the STOP key to halt the 
program, but this is not really satisfactory. 

Accordingly, we have included another version of 
TYPE on the enclosed Program Disk. This program 
will correctly echo any character it can read from an 
ASCII text file and will correctly pause the listing one 
screen at a time. 

Compare this version of TYPE with the version 
from your previous module. Both programs are 
written in BASIC and do not require FAS. However, 
the enclosed version of TYPE uses more sophisti- 
cated techniques to produce a cleaner, more 
readable result. 
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Sector 3: Problems for Next Time 


You have now worked with the PDSW program and 
compared your results with ours. You have also 
compared the two versions of the TYPE program. 
Now, to gain experience in working with assembly 
language and in modifying programs while you are 
waiting for your next module, try making further 
changes to both of these programs. 

To the PDSW program, extend the graphics table 
so that the program will be able to output graphics 
as well as upper- and lower-case letters, numbers, 
and punctuation marks. One way to handle this is to 
let bit 7 of each character designate whether the 
character is alphanumeric or graphic. Thus, the 
existing characters will remain unchanged, and 
characters with bit 7 set (ASCII codes 128 through 
255) can represent graphics characters. 

To make the graphics characters touch each 
other on all four sides, you will have to alter the 


program so that the blanks between characters and 
lines are part of the graphics table, rather than part 
of the program. Remember to plan carefully before 
you actually modify the program. 

The second problem for you to work on is a 
further modification of the TYPE program. While 
waiting for your next module, try rewriting TYPE as 
an assembly-language program rather than a 
BASIC program. You have already worked with all 
of the routines and methods that you will require 
here; all you need to do is to rearrange them to 
match this different task. 

In your next module, we will have an expanded 
version of PDSW, as well as an assembly-language 
version of TYPE, for you to compare with your own 
efforts. Until then, happy programming! 
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